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REMARKS 

Applicant replies to the Final Office Action mailed on April 2, 2007 within two months. 
Thus, Applicant respectfully requests an Advisory Action, if necessary. Claims 1-11 were 
pending in the application and the Examiner rejects claims 1-11. Support for the amendments 
may be found in the originally-filed specification, claims, and figures. No new matter has been 
introduced by these amendments. Reconsideration of this application is respectfully requested. 

Rejection under 35 U.S.C. § 102(b) 

The Examiner rejects claims 1-6 and 8-11 under 35 U.S.C. § 102(b) as being anticipated 
by Coleman, U.S. Patent 5,708,828 ("Coleman"). Applicant respectfully traverses this rejection. 

In response to Applicant's previously filed arguments contending that Coleman teaches 
the use of more than a single translation of data, the Examiner asserts that, "Applicant's have not 
claimed the single translation from an output format, such that only the output format is natively 
useable by particular software where the input format cannot be used" (page 4, "Examiners 
Response"). Applicant respectfully disagrees, however, to expedite prosecution, Applicant 
amends independent claim 1 to more clearly recite the step of converting data from a first format 
to a format that is usable by a second source. Support for the amendment may be found, for 
example, in paragraphs 12 and 13 of the originally filed specification, which recites in part, "data 
is converted by Interface File Builder 210 to a format usable by company" (paragraph 12). 

Moreover, one of ordinary skill in art would appreciate that because the data is being 
converted to a format usable by a second source, the data at the first source was initially unusable 
prior to the conversion. This is inherent throughout the teachings of the originally filed 
specification, which seeks to solve the problem of converting data between disparate data 
sources in order for data from foreign systems to be usable by native systems. 

The Examiner next asserts that even if Applicant's claimed a single translation from an 
unusable format to a useable format, Coleman, "clearly describes this as the prior art system of 
Figure 1" (page 4, paragraph 1). Applicant respectfully disagrees. 

It is important to note that Coleman describes Figure 1 as "the data conversion system 
and method of the present invention"; therefore, Figure 1 itself is not directed to a prior art 
system that existed prior to Coleman, as the Examiner contends. As such, Figure 1 provides a 
very high-level view describing the Coleman interactions between a data source (mainframe 
computer), a computer system executing the data conversion system and method, and a data 
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recipient for receiving the converted data. Notably, it. is the computer system executing the data 
conversion system and method that performs the multi-stepped conversion process, as disclosed 
by Coleman. A closer analysis of Coleman's multi-stepped conversion process will be provided 
herein. 

The Examiner furthermore asserts that Coleman "discloses a single translation from the 
input format to the pre-defined generic data format as shown by figure 2b" (page 4, paragraph 2). 
Applicant agrees that Coleman discloses a single translation step to convert source data of a first 
format to data of a generic format. However, the generic format as described by Coleman is not 
useable by a data recipient. Thus, Coleman discloses a second translation step to convert the 
generic data format to a format that is usable by the data recipient. As noted above in reference 
to amended claim 1, Coleman does not disclose a single translation step to convert data from a 
first unusable format to a second usable format. In light of the amendment and aforementioned 
arguments, Applicant respectfully requests that the Examiner consider the differentiating factors 
between the presently claimed invention and the Coleman reference. 

Coleman discloses a data translation process, which begins with creating what is termed 
an "environment," and extends to rendering and storing translated data. The environment is 
disclosed as being a combination of definitions and rules that are used to translate the data from 
the first format to a second generic format; and from the second generic format to a third format. 
According to Coleman, an environment can be created based on the specific data translation 
needs. For example, if a user needs to move data from a source Microsoft SQL Server database 
to a destination UNIX data file, the user may interface with the Coleman system to define the 
source and the destination. On the source side, this may require the user to create a pointer to the 
database, define which fields in the database need to be converted, and specify the data type for 
each field. On the destination side, the user may create a pointer to where the data file exists, 
specify how the data is to be formatted, and define the data type. When the definitions have been 
created and saved to memory, Coleman refers to the definitions as a single data-mapping object. 

Coleman further discloses an "intermediate output environment" (not to be mistaken with 
the "environment" described above) as follows: 

"Intermediate output environments are used for a variety of reasons including, 
first, to simplify the migration process itself by separating the process into 
smaller, more workable parts; second, to move a single store of imported data to 
multiple data base output files or even multiple different data base platforms; and 
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third, to parse records into different output files for loading into separate 
databases. . ." (column 3, lines 46-53). 

Thus, the intermediate output environment is optionally used to pre-process data from a first data 
environment to simplify complex migration tasks. In other words, implementation of an 
intermediate output environment is not related to, nor does it negate the need for multiple 
translation steps. See, for example, Fig. 3 that discloses at step 201 receiving definition of any 
desired intermediate formats. Much later in the process (i.e., step 214), a migration takes place, 
wherein there is a conversion of data from a first input data environment to data having a pre- 
defined generic data type. Finally, in step 216, there is an execution of associations to convert 
data in the pre-defined generic data type to produce "output data" in accordance with a second 
data format. 

As further evidence of the separation between the "intermediate output environment" and 
the "pre-defined generic data type; Coleman discloses the following: 

"Intermediate output environments behave identically to normal output 
environments, and the process used to declare or create an intermediate output 
environment is identical to the process used to create input or output 
environments described above" (column 3, lines 53-57). 

Thus, it is clear that the intermediate output environment, as disclosed by Coleman, can be most 
closely compared to the output environment, and that it is processed in the same manner as a 
normal input environment. That is, an intermediate output environment is created by converting 
data from an input data environment to a pre-defined generic data type (first translation), and is 
then converted from the pre-defined generic data type to a format suitable for the output data 
environment (second conversion). As such, Coleman does not disclose or suggest at least, 
"translating, via said host computer, using only a single translation of said unusable data from 
said first source to a format usable by a second source according to said definitions contained in 
said interface file, wherein said unusable data from said first source is usable by said second 
source after said translating step," as recited by independent claim 1 . 

Claims 2-6 and 8-11 variously depend from independent claim 1. As such, dependent 
claims 2-6 and 8-11 are differentiated from the cited reference for at least the reasons set forth 
above, as well as in view of their own respective features. 
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The Examiner rejects claim 7 under 35 U.S.C. § 103(a) as being unpatentable over 
Coleman in view of Free On-Line Dictionary of Computing definition of the term "wizard" 
("Foldoc"). Applicant respectfully traverses this rejection. 

Neither Coleman, Foldoc, nor any combination thereof, disclose or suggest at least, 
"translating, via said host computer, using only a single translation of said unusable data from 
said first source to a format usable by a second source according to said definitions contained in 
said interface file, wherein said unusable data from said first source is usable by said second 
source after said translating step," as recited by independent claim 1 from which claim 7 
depends. Thus, claim 7 is differentiated from the cited references for at least the same reasons as 
set forth above, as well as in view of its own respective features. 

In view of the above remarks, Applicant respectfully submits that all pending claims 
properly set forth that which Applicant regards as his invention and are allowable over the cited 
references. Accordingly, Applicant respectfully request allowance of the pending claims. The 
Examiner is invited to telephone the undersigned at the Examiner's convenience, if that would 
help further prosecution of the subject application. Attorney for Applicant authorizes and 
respectfully requests that any fees due be charged to Deposit Account No. 19-2814. 
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